Conversation
| // Risk of overflow should be extremely small, even if milk.last = 0; | ||
| // can anyway be made less likely to overflow with a little more work. | ||
| uint256 pile = mul(sub(block.timestamp, milk.last) / milk.qntm, milk.clod); | ||
| pile = min(milk.dirt, milk.trid, pile); |
There was a problem hiding this comment.
given trid <= dirt, why is dirt needed here?
| uint256 trid; // Amt of dirt dug by auctions. [rad] | ||
| // Packed in to a single slot to minimze gas costs. | ||
| uint224 clod; // Amount of dirt to remove per time quantum [rad] | ||
| uint32 qntm; // Time between removal of clods [seconds] |
There was a problem hiding this comment.
how about removing this and setting clod in a per-second basis to save some gas?
|
So the assumption here is that during sharp price declines |
|
After thinking about this a lot, I think that making
What I really like about this option, is that it would be a pretty small code change, possibly easier to audit and verify. |
2 participants
DO NOT MERGE, FOR DISCUSSION PURPOSES ONLY
Here's a basic implementation of a
holethat decays in a stepwise linear fashion.It's stepwise because a continuous decrease would likely lead to too many small auctions in a case where we bumped into a
holelimit.Every
qntmseconds,dirtcan decrease by up toclod. This is triggered inbark(adds a lot ofSSTOREops, so incentives will matter). But the decrease is only allowed if enough DAI has been collected from auctions or is no longer associated with an auction. This is tracked astrid(dirtthat has been "reversed"), so that if auctions are failing to recapitalize, we don't continue to liquidate. I think there may be an argument for removing this and simplifying to a purely time-based mechanism, but wanted to start from this formulation.